[SIL][Optimizer] eliminate @pack_element types #85333
Conversation
SwiftCompilerSources/Sources/Optimizer/InstructionSimplification/SimplifyAllocStack.swift
Outdated
Show resolved
Hide resolved
SwiftCompilerSources/Sources/Optimizer/InstructionSimplification/SimplifyAllocStack.swift
Show resolved
Hide resolved
SwiftCompilerSources/Sources/Optimizer/InstructionSimplification/SimplifyAllocStack.swift
Outdated
Show resolved
Hide resolved
SwiftCompilerSources/Sources/Optimizer/InstructionSimplification/SimplifyAllocStack.swift
Outdated
Show resolved
Hide resolved
...tCompilerSources/Sources/Optimizer/InstructionSimplification/SimplifyUncheckedAddrCast.swift
Outdated
Show resolved
Hide resolved
...tCompilerSources/Sources/Optimizer/InstructionSimplification/SimplifyUncheckedAddrCast.swift
Show resolved
Hide resolved
...tCompilerSources/Sources/Optimizer/InstructionSimplification/SimplifyUncheckedAddrCast.swift
Outdated
Show resolved
Hide resolved
SwiftCompilerSources/Sources/Optimizer/InstructionSimplification/SimplifyWitnessMethod.swift
Outdated
Show resolved
Hide resolved
elsakeirouz
force-pushed
the
eliminate-pack_element-types
branch
4 times, most recently
from
4db84e1 to
ae181f8
Compare
* SwiftCompilerSources/Sources/AST/Type.swift * SwiftCompilerSources/Sources/Optimizer/InstructionSimplification/SimplifyAllocStack.swift * SwiftCompilerSources/Sources/Optimizer/InstructionSimplification/SimplifyUncheckedAddrCast.swift * SwiftCompilerSources/Sources/Optimizer/InstructionSimplification/SimplifyWitnessMethod.swift * SwiftCompilerSources/Sources/Optimizer/Utilities/OptUtils.swift * include/swift/AST/ASTBridging.h * include/swift/AST/ASTBridgingImpl.h
elsakeirouz
force-pushed
the
eliminate-pack_element-types
branch
2 times, most recently
from
491bbf8 to
71d3673
Compare
There was a problem hiding this comment.
Hmm. Can we reasonably just ask SILCloner to canonicalize this, so that we don't end up with pack_element archetypes that can be resolved to a concrete type in the first place? Otherwise I'm concerned that we're going to play whack-a-mole with every instruction that takes a type operand.
I think this can be done elegantly with a combination of
- specializing the cloning of
DynamicPackIndexInstto turn it into aScalarPackIndexInstwhen the index value is aninteger_literaland there's a prefix of non-expansion element types in the pack (which I don't think you're checking for), and - specializing the cloning of
OpenPackElementInstwhen the index is aScalarPackIndexInst.
The result of OpenPackElementInst is only used as a type-dependent operand for uses of the local archetype it produces, so it should be fine to simply not create a corresponding value in the clone.
You may also need to do some similar canonicalization with PackPackIndexInst; the test case is a variadic generic function that creates a larger pack, e.g.
func foo<each T>(values: repeat each T) {}
func bar<each T>(values: repeat each T) {
foo(values: repeat each values, 1, 2, 3)
}
That's an interesting idea. However, when the cloner runs to specialize the pack for concrete types, the pack loop is still not unrolled and pack indices are not constant folded, etc. So it cannot see the constant element type.
Good catch! This check needs to be added |
Unrolling the loop is presumably also going to be done by the SILCloner.
Okay, then add it as a specific override in the cloner you use to unroll the pack loop. Or if you really want to do this retroactively instead of while you're unrolling (which is going to mean cloning almost all the instructions in the loop body twice per unroll, but okay), you should just have the optimizer recognize that you can fold an The point is that this is just a type substitution. We have a standard code path for rewriting every kind of instruction under a type substitution, which is the SIL cloner, and we should not be making redundant partial copies of that logic.
There are more than a few relevant instructions, though. Almost every use of the pack element would benefit from knowing that it's a specific type. The goal of this optimization should be to eliminate the pack element archetype entirely, and the most reasonable way to do that is with a SIL cloner that has the effect of replacing the pack element archetype with the concrete pack element type in the unrolled loop body.
The existential archetype specialization code should also be using the SIL cloner to substitute the existential archetype with the erased type, rather than hard-coding that for specific instructions. |
That's a reasonable approach |
4 participants
Most variadic generic functions contain loops that iterate over the elements of their Pack parameters. Since the types of the pack elements are unknown, witness table methods are used to perform operations on the current pack element in each iteration. After specialization, these loops are usually unrolled, since there is a fixed list of pack element types. In the unrolled code, it should be possible to eliminate the witness table lookups. This is not possible because of the @pack_element types introduced to refer to pack elements:
%5 = integer_literal $Builtin.Word, 0
%6 = dynamic_pack_index %5 of $Pack{Int, Double}
%7 = open_pack_element %6 of at <Pack{Int, Double}>, shape $each A, uuid "063BDCF4-98A3-11F0-B2E8-929C59BC796C"
%20 = witness_method $@pack_element("063BDCF4-98A3-11F0-B2E8-929C59BC796C") each A, #Numeric."*" …
%21 = apply %20<@pack_element("063BDCF4-98A3-11F0-B2E8-929C59BC796C") each A>(%10, %14, %18, %11) … // type-defs: %7
This simplification aims to eliminate all instances of @pack_element types from specialized functions by replacing those with the underlying concrete type. This allows the appropriate witness method, as well as other functions, to be inlined.
This computed attribute is used in the simplifications of witness_method, alloc_stack, unchecked_addr_cast and apply.